System traffic analyzers to request co-location of virtual machines in frequent communication

ABSTRACT

Examples described herein include distributed computing systems having a system traffic analyzer. The system traffic analyzer may receive sampled packets sent to a network from a number virtual machines hosted by computing nodes in the distributed computing system. The packets may be sampled, for example, by network flow monitors in hypervisors of the computing nodes. The system traffic analyzer may request co-location of virtual machines having greater than a threshold amount of traffic between them. The request for co-location may result in the requested virtual machines being hosted on a same computing node, which may in some examples conserve network bandwidth.

TECHNICAL FIELD

Embodiments described herein relate generally to virtual computingsystems, and examples of traffic control monitors are described whichmay affect placement of virtual machines in a computing system.

BACKGROUND

As datacenters scale, operational complexity increases. Additionally,network bandwidth may be a resource of concern in a distributedcomputing system, such as a virtual computing system. Generally,computing nodes in a distributed computing system may communicate withone another over a network. It may be desirable to reduce traffic overthat network while maintaining system performance.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a distributed computing system, inaccordance with an embodiment of the present invention.

FIG. 2A and FIG. 2B are schematic illustrations of actions of a systemarranged in accordance with examples described herein.

FIG. 3 is an example of decoded sample packet data arranged inaccordance with examples described herein.

FIG. 4 is an example listing of VM identifiers and hosts arranged inaccordance with examples described herein.

FIG. 5 is a flowchart illustrating a method arranged in accordance withexamples described herein.

FIG. 6 depicts a block diagram of components of a computing node 200 inaccordance with an embodiment of the present invention.

DETAILED DESCRIPTION

Certain details are set forth below to provide a sufficientunderstanding of described embodiments. However, it will be clear to oneskilled in the art that embodiments may be practiced without various ofthese particular details. In some instances, well-known computing systemcomponents, circuits, control signals, timing protocols, and/or softwareoperations have not been shown in detail in order to avoid unnecessarilyobscuring the described embodiments.

Examples described herein include distributed computing systems having asystem traffic analyzer. The system traffic analyzer may receive sampledpackets sent to a network from a number virtual machines hosted bycomputing nodes in the distributed computing system. The packets may besampled, for example, by network flow monitors in hypervisors of thecomputing nodes. The system traffic analyzer may request co-location ofvirtual machines having greater than a threshold amount of trafficbetween them. The request for co-location may result in the requestedvirtual machines being hosted on a same computing node, which may insome examples conserve network bandwidth.

FIG. 1 is a block diagram of a distributed computing system (e.g. avirtual computing system), in accordance with an embodiment of thepresent invention. The distributed computing system of FIG. 1 generallyincludes computing node 102 and computing node 112 and storage 140connected to a network 122. The network 122 may be any type of networkcapable of routing data transmissions from one network device (e.g.,computing node 102, computing node 112, and storage 140) to another. Forexample, the network 122 may be a local area network (LAN), wide areanetwork (WAN), intranet, Internet, or a combination thereof. The network122 may be a wired network, a wireless network, or a combinationthereof.

The storage 140 may include local storage 124, local storage 130, cloudstorage 136, and networked storage 138. The local storage 124 mayinclude, for example, one or more solid state drives (SSD 126) and oneor more hard disk drives (HDD 128). Similarly, local storage 130 mayinclude SSD 132 and HDD 134. Local storage 124 and local storage 130 maybe directly coupled to, included in, and/or accessible by a respectivecomputing node 102 and/or computing node 112 without communicating viathe network 122. Cloud storage 136 may include one or more storageservers that may be stored remotely to the computing node 102 and/orcomputing node 112 and accessed via the network 122. The cloud storage136 may generally include any type of storage device, such as HDDs SSDs,or optical drives. Networked storage 138 may include one or more storagedevices coupled to and accessed via the network 122. The networkedstorage 138 may generally include any type of storage device, such asHDDs SSDs, or optical drives. In various embodiments, the networkedstorage 138 may be a storage area network (SAN).

The computing node 102 is a computing device for hosting virtualmachines (VMs) in the distributed computing system of FIG. 1. Thecomputing node 102 may be, for example, a server computer, a laptopcomputer, a desktop computer, a tablet computer, a smart phone, or anyother type of computing device. The computing node 102 may include oneor more physical computing components, such as processors.

The computing node 102 is configured to execute a hypervisor 110, acontroller VM 108 and one or more user VMs, such as user VMs 104, 106.The user VMs including user VM 104 and 106 are virtual machine instancesexecuting on the computing node 102. In some examples, the VM 106 may bea system traffic analyzer as shown in FIG. 1 and described herein. Inother examples, a system traffic analyzer may be separate from thecomputing node 102. The user VMs including user VM 104 and 106 may sharea virtualized pool of physical computing resources such as physicalprocessors and storage (e.g., storage 140). The user VMs including userVM 104 and 106 may each have their own operating system, such as Windowsor Linux. While a certain number of user VMs are shown, generally anynumber may be implemented.

While a system traffic analyzer 106 is shown implemented as a user VM inFIG. 1, in other examples, the system traffic analyzer may be locatedelsewhere in the distributed computing system. For example, systemtraffic analyzers described herein may be implemented as user VMs, inbare metal, in the cloud, or in another location. Generally, systemtraffic analyzers may be connected (e.g., over network 122) tocommunicate with network flow monitors described herein to receivesampled packets.

The hypervisor 110 may be any type of hypervisor. For example, thehypervisor 110 may be ESX, ESX(i), Hyper-V, KVM, or any other type ofhypervisor. The hypervisor 110 manages the allocation of physicalresources (such as storage 140 and physical processors) to VMs (e.g.,user VM 104, 106, and controller VM 108) and performs various VM relatedoperations, such as creating new VMs and cloning existing VMs. Each typeof hypervisor may have a hypervisor-specific API through which commandsto perform various operations may be communicated to the particular typeof hypervisor. The commands may be formatted in a manner specified bythe hypervisor-specific API for that type of hypervisor. For example,commands may utilize a syntax and/or attributes specified by thehypervisor-specific API. In examples described herein, hypervisors mayinclude a network flow monitor. For example, hypervisor 110 includesnetwork flow monitor 146 and hypervisor 120 includes network flowmonitor 148. Examples of network flow monitors include netflow andsflow.

Network flow monitors described herein, such as the network flow monitor146 and network flow monitor 148 may examine packets sent to and/or fromthe computing node in which they are operating (e.g., the computing node102 and computing node 112, respectively). In examples described herein,network flow monitors may sample packets sent to and/or from thecomputing node in which they are operating. The sampled packets may besent to a system traffic analyzer described herein, such as systemtraffic analyzer 106 of FIG. 1.

Controller VMs described herein, such as the controller VM 108 and/orcontroller VM 118, may provide services for the user VMs in thecomputing node. As an example of functionality that a controller VM mayprovide, the controller VM 108 may provide virtualization of the storage140. Controller VMs may provide management of the distributed computingsystem shown in FIG. 1. In some examples, the controller VM 108 mayinclude a hypervisor independent interface software layer that providesa uniform API through which hypervisor commands may be provided.Generally, the interface through which a user or VM interacts with thehypervisor may not dependent on the particular type of hypervisor beingused. For example, the API that is invoked to create a new VM instancemay appear the same to a user regardless of what hypervisor theparticular computing node is executing (e.g. an ESX(i) hypervisor or aHyper-V hypervisor). The controller VM 108 may receive a command throughits uniform interface (e.g., a hypervisor agnostic API) and convert thereceived command into the hypervisor specific API used by the hypervisor110.

The computing node 112 may include user VM 114, user VM 116, acontroller VM 118, and a hypervisor 120. The user VM 114, user VM 116,the controller VM 118, and the hypervisor 120 may be implementedsimilarly to analogous components described above with respect to thecomputing node 102. For example, the user VM 114 and user VM 116 may beimplemented as described above with respect to the user VM 104 and 106.The controller VM 118 may be implemented as described above with respectto controller VM 108. The hypervisor 120 may be implemented as describedabove with respect to the hypervisor 110.

Generally, each distributed computing system may have a single systemtraffic analyzer described herein. Sampled packets from each node in thedistributed computing system may be sent to a shared system trafficanalyzer (e.g., sampled packets from computing node 102 and computingnode 112 may be provided to system traffic analyzer 106 of FIG. 1).

The controller VM 108 and controller VM 118 may communicate with oneanother via the network 122. By linking the controller VM 108 andcontroller VM 118 together via the network 122, a distributed network ofcomputing nodes including computing node 102 and computing node 112, canbe created.

Controller VMs, such as controller VM 108 and controller VM 118, mayeach execute a variety of services and may coordinate, for example,through communication over network 122. Services running on controllerVMs may utilize an amount of local memory to support their operations.For example, services running on controller VM 108 may utilize memory inlocal storage 124. Services running on controller VM 118 may utilizememory in local storage 130. Moreover, multiple instances of the sameservice may be running throughout the distributed system—e.g. a sameservices stack may be operating on each controller VM. For example, aninstance of a service may be running on controller VM 108 and a secondinstance of the service may be running on controller VM 118.

System traffic analyzer 106 may have some storage attached to it (e.g.,a database storing traffic data 142). The storage for the traffic data142 may be coupled to (e.g., in communication with) the computing node102. The storage for the system traffic analyzer 106 may be locatedanywhere in the system, e.g., in the storage 140 or in another location.The system traffic analyzer 106 may access stored associations between1P addresses and VM identifiers. For example traffic data 142 mayinclude a database, list, or other data structure storing an associationbetween an IP address and VM identifier. For example, IP addressesassociated with each of user VM 104, user VM 114, and user VM 116 may bestored associated with an identifier for user VM 104, user VM 114, anduser VM 116, respectively. While traffic data 142 is illustrated in FIG.1 as a single database, in other examples traffic data 142 may bedistributed across multiple databases and/or storage devices.

During operation, network flow monitors in the hypervisors of computingnodes described herein may sample packets sent from the nodes onto anetwork, and provide sampled packets. For example, the network flowmonitor 148 may sample packets that user VM 114 and/or user VM 116 sendover the network 122. The packets may be sampled, for example bycapturing a leading number of bits from each packet to provide sampledpackets. The sampled packets from the computing node 112 may be providedto the system traffic analyzer 106. Similarly, the network flow monitor146 may sample packets sent by the user VM 104 to the network 122 andmay provide the sampled packets to the system traffic analyzer 106.Generally, any number of VMs may be located on each computing node, andthe network flow monitor provided in the hypervisor of the computingnode may sample packets from any and/or all of the VMs hosted by thecomputing node.

The system traffic analyzer 106 may decode sampled packets received toprovide decoded packets. For example, the system traffic analyzer mayidentify IP addresses and/or other information contained in the sampledpackets. Information contained in the sampled packets which may beidentified (e.g., decoded) includes, for example, a source IP address, adestination IP address, a source port, a destination port, a protocol,or combinations thereof. The system traffic analyzer may access dataassociating the IP addresses with VM identifiers. In this manner, thesystem traffic analyzer 106 may translate IP addresses into VMidentifiers and the system traffic analyzer 106 may identify the sourceVM, the destination VM, and/or the source and/or destination host (e.g.,computing node) for any and/or all of the received sampled packets.

The traffic data 142 database may store traffic data that may be basedon the decoded packets. For example, the traffic data 142 may includedata about number and/or rate of packets sent from and/or to particularVMs. The traffic data 142 may further indicate which VMs are running onwhich computing nodes (e.g., which computing nodes are hosting the VMsidentified).

The system traffic analyzer 106 analyzes the data stored in traffic data142 and may request virtual machines be migrated based on the trafficdata 142. For example, the system traffic analyzer 106 may provide arequest to migrate virtual machines when traffic between at least onevirtual machine on one computing node (e.g., computing node 102) and atleast one virtual machine on a second computing node (e.g., computingnode 112) is above a threshold level as reflected in traffic data 142.The threshold level may vary, for example, based on time of day, day ofthe week, day of the month, season of the year, etc. In this manner, thethreshold level may be set such that it is greater than an expectedand/or tolerated amount of traffic between two VMs. In some examples,the threshold level may be set as a persistent threshold level such thata request to co-locate the VMs is not generated until traffic betweenthem exceeds a threshold level for greater than a threshold time. Inthis manner, a transient burst of traffic may not cause a request forco-location. The threshold time may be measured, for example, inmilliseconds, seconds, minutes, hours, days, or weeks.

For example, if user VM 104 and user VM 114 are having frequentcommunication, the system traffic analyzer 106 may request that the userVM 104 and/or user VM 114 be migrated such that they are located on thesame computing node. For example, user VM 104 may be migrated tocomputing node 112 and/or user VM 114 may be migrated to computing node102. Locating two VMs which are having increased communication (e.g.,“chatty VMs”) may conserve bandwidth on network 122 because, whenco-located, VMs may not require communication over network 122.

Generally, requests for migration provided by system traffic analyzersdescribed herein may be provided to one or more distributed resourcescheduler(s). The distributed resource scheduler(s) may be executing onany of the computing nodes in the system of FIG. 1, such as computingnode 102 and/or computing node 112. A distributed resource scheduler mayreceive a request to migrate one or more virtual machines from a systemtraffic analyzer described herein, such as system traffic analyzer 106.The distributed resource scheduler may determine, based on the request,to migrate one or more virtual machines to be co-located on a same host.The virtual machine migrated, the surviving host selected, and/or timingand other details of a migration may be determined by the distributedresource scheduler. The distributed resource scheduler may take otherfactors into account in determining if and how to effect a migration.For example, the distributed resource scheduler may also administeranti-affinity schemes, where certain VMs may have a preference againsthaving a same host (e.g., for security or other reasons). Accordingly,in some examples a system traffic analyzer may request a migration, butthe distributed resource scheduler may not implement the migration(e.g., if the VMs requested for co-location are also indicated asanti-affinity). In other examples, the distributed resource schedulerwill effect a request from the system traffic analyzer. For example, thedistributed resource scheduler may receive a request from a systemtraffic analyzer to co-locate (e.g., host on a same computing node) twoVMs. The distributed resource scheduler may migrate VMs such that therequested VMs are located on a same computing node. One VM may bemigrated by the distributed resource scheduler to the other VM's host.The surviving host may be selected, for example, by selecting the hostwhich has a lesser amount of current traffic. In some examples, thedistributed resource scheduler may receive a request from the systemtraffic analyzer to co-locate two VMs. In some examples, the distributedresource scheduler may migrate both VMs to a different, third computingnode where they may be co-located. In some examples, the surviving hostmay be a host having a least traffic load of all hosts of the virtualmachines to be co-located.

FIGS. 2A and 2B are schematic illustrations of actions of a systemarranged in accordance with examples described herein. The systems shownin FIGS. 2A and 2B may be used to implement and/or may be implemented bythe system of FIG. 1 in some examples. In the example of FIGS. 2A and2B, three computing nodes are shown in the distributed computingsystem—computing node 206, computing node 208, and computing node 210.The system is shown at two time periods—time 202 and time 204. At time202, the computing node 206 hosts three virtual machines—VM1, VM2, andVM3. At time 202, the computing node 208 hosts three virtualmachines—VM4, VM5, and VM6. At time 202, the computing node 210 hosts asingle virtual machine VM7.

One of the computing nodes in the system of FIGS. 2A and 2B may host asystem traffic analyzer, such as the system traffic analyzer 106 ofFIG. 1. In some examples, a system traffic analyzer may be operating inthe system on another computing device not shown in FIGS. 2A and 2B.Each of the nodes—computing node 206, computing node 208, and computingnode 210 may include a hypervisor having a network flow monitor, e.g.,network flow monitor 146 and/or network flow monitor 148. The networkflow monitors may provide sampled packets from all computing nodes tothe system traffic analyzer. The system traffic analyzer may decode thesampled packets, identify source VM, destination VM, and/or source anddestination host computing node, for each of the sampled packets.

In the example of FIGS. 2A and 2B, the system traffic analyzer maydetermine that traffic between VM3 on computing node 206 and VM6 oncomputing node 208 exceeds a threshold level. In some example, thesystem traffic analyzer may determine that traffic between VM3 oncomputing node 206 and VM6 on computing node 208 has exceeded athreshold level for greater than a threshold time. Responsive to thisdetermination, the system traffic analyzer may request co-location ofVM3 and VM6. Responsive to the request, a distributed resourcescheduler, which may be operating on any of the computing nodes shown,or on another computing system in communication with the system of FIGS.2A and 2B, may migrate at least one VM to achieve the co-location. Inthe example of FIGS. 2A and 2B, the distributed resource scheduler attime 204 has migrated VM3 from computing node 206 to computing node 208.At time 204, the virtual machines VM3 and VM6 are co-located on a samecomputing node and no longer require a between-node network forcommunication. This may advantageously conserve network bandwidth insome examples.

While in this example, two VMs are shown as being co-located, any numbermay be requested to be co-located by system traffic analyzers describedherein, including 3, 4, 5, 6, 7, 8, 9, 10, or another number of VMs.

FIG. 3 is an example of decoded sample packet data arranged inaccordance with examples described herein. The data shown in FIG. 3 maybe stored, for example, in traffic data 142 of FIG. 1 in some examples.FIG. 3 illustrates a source, destination, host, cluster, application,and size (e.g., “bytes”) column. A system traffic analyzer, such assystem traffic analyzer 106 of FIG. 1, may populate the columns as itdecodes each received sample packet. Reviewing a first line of datashown in FIG. 3 (which represents a packet), the packet originated fromsource VM having the VM identifier ‘example-10’. VM identifiers may betext strings, numerical strings, or combinations thereof. Reviewing thatfirst line of data again, the destination VM had the VM identifier‘example-1’. The host sending the packet had a host identifier (e.g.,name) “HOST-D”. The cluster (e.g., distributed system) sending thepacket had a cluster identifier ‘example’. The application associatedwith the packet was ftp. The number of bytes in the packet was 655.29MB.

Reviewing the second line of data, representing a second sampled packet,in FIG. 3, the source VM sending the packet had a VM identifier of‘-example-1’, the destination VM for receipt of the packet had a VMidentifier of ‘-example-10’. The host computing node sending the packetwas “HOST-B”, the cluster sending the packet was ‘example’, theapplication sending the packet was ftp, and the bandwidth was 651.04 MB.

In the example of FIG. 3, the system traffic analyzer, such as thesystem traffic analyzer 106 of FIG. 1, may identify that there istraffic between “example-10” and “example-1” which exceeds a thresholdlevel. Note that “example-10” and “example-1” are hosted on differenthosts. Accordingly, the system traffic analyzer may request that the VMsbe migrated such that they are co-located.

FIG. 4 is an example listing of VM identifiers and hosts arranged inaccordance with examples described herein. As described with referenceto FIG. 3, a system traffic analyzer may request co-location of the VMsidentified by ‘example-1’ and ‘example-10’. The request may be providedto a dynamic resource scheduler, which may affect the request. FIG. 4 isan illustration of a table associating VM identifiers (e.g., names) withhosts. The data in FIG. 4 is displayed after the dynamic resourcescheduler effected the request to co-locate ‘example-1’ and‘example-10’. As can be seen in FIG. 4, ‘example-1’ and ‘example-10’ areboth now hosted on the host named “HOST-D”, which previously only hosted“example-10”. In other examples, the surviving host could have been thehost of “example-1”. In other examples, both “example-10” and“example-1” may have been migrated to a different common host.

FIG. 5 is a flowchart illustrating a method arranged in accordance withexamples described herein. The method 500 includes block 502, block 504,block 506, and block 508. In some examples, the blocks may be providedin a different order. In some examples, additional and/or fewer blocksmay be used.

In block 502, network packets that are sent over a network between VMsmay be sampled. The network packets may be sampled by network flowmonitors provided in one or more hypervisors. For example, referring toFIG. 1, packets sent between computing node 102 and computing node 112may be sampled by network flow monitor 146 and network flow monitor 148,respectively. The sampling may include copying and/or accessing aleading number of bits of each packet. In some examples, the samplingmay include accessing a different predetermined region of bits of eachpacket. Each packet transmitted by the computing node over the network122 may be sampled in some examples. In some examples, fewer than eachpacket may be sampled—e.g., every other packet, every fifth packet,every tenth packet, every 100th packet, every 1000th packet, etc. Thesampled network packets may be provided to a system traffic analyzer,e.g., system traffic analyzer 106 of FIG. 1.

In block 504, which may follow block 502, the sampled network packetsmay be analyzed (e.g., by the system traffic analyzer) to identifysource and destination IP addresses. In some examples, the samplednetwork packets may be decoded by the system traffic analyzer, which mayaid in identifying the source and destination IP addresses.

In block 506, which may follow block 504, the source and destination IPaddresses may be translated into virtual machine identifiers (e.g.,virtual machine names). For example, the system traffic analyzer 106 ofFIG. 1 may access data (e.g., data in traffic data 142) that associatesIP addresses with virtual machine identifiers. The source anddestination IP addresses, source and destination virtual machineidentifiers, and/or other data discerned from the sampled networkpackets may be stored—in traffic data 142 of FIG. 1. Other data mayinclude host name of a computing node hosting the source VM, size,and/or application originating the packet.

In block 508, which may follow block 506, a request may be provided toco-locate VMs when traffic between the VMs exceeds a threshold level.The requested may be provided by system traffic analyzers describedherein based on traffic data accumulated by the system traffic analyzers(e.g., by system traffic analyzer 106 of FIG. 1 based on traffic data142). The threshold level may be set specific to a VM, host,application, or time of day, week, year, month, etc. In some examples,the request may not be made unless the traffic exceeds a threshold levelfor greater than a threshold time to avoid requesting a migrationfollowing a short traffic increase.

In some examples, the request provided in block 508 may be sent to ascheduler (e.g., a dynamic resource scheduler), which may affect therequest if allowed in combination with other rules enforced by thedynamic resource scheduler (e.g., in view of any anti-affinity rulespreventing co-location of certain VMs). The dynamic resource schedulermay further determine which computing node should host the co-locatedVMs in accordance with resource usage at the candidate host VMs. In someexamples, the surviving host hosting the co-located VMs nay be one ofthe hosts initially hosting one of the VMs requested to be co-located.

FIG. 6 depicts a block diagram of components of a computing node 600 inaccordance with an embodiment of the present invention. It should beappreciated that FIG. 6 provides only an illustration of oneimplementation and does not imply any limitations with regard to theenvironments in which different embodiments may be implemented. Manymodifications to the depicted environment may be made. The computingnode 600 may implemented as and/or may be used to implement thecomputing node 102 and/or computing node 112 of FIG. 1.

The computing node 600 includes a communications fabric 602, whichprovides communications between one or more processor(s) 604, memory606, local storage 608, communications unit 610, I/O interface(s) 612.The communications fabric 602 can be implemented with any architecturedesigned for passing data and/or control information between processors(such as microprocessors, communications and network processors, etc.),system memory, peripheral devices, and any other hardware componentswithin a system. For example, the communications fabric 602 can beimplemented with one or more buses.

The memory 606 and the local storage 608 are computer-readable storagemedia. In this embodiment, the memory 606 includes random access memoryRAM 614 and cache 616. In general, the memory 606 can include anysuitable volatile or non-volatile computer-readable storage media. Thelocal storage 608 may be implemented as described above with respect tolocal storage 124 and/or local storage 130. In this embodiment, thelocal storage 608 includes an SSD 622 and an HDD 624, which may beimplemented as described above with respect to SSD 126, SSD 132 and HDD128, HDD 134 respectively.

Various computer instructions, programs, files, images, etc. may bestored in local storage 608 for execution by one or more of therespective processor(s) 604 via one or more memories of memory 606. Insome examples, local storage 608 includes a magnetic HDD 624.Alternatively, or in addition to a magnetic hard disk drive, localstorage 608 can include the SSD 622, a semiconductor storage device, aread-only memory (ROM), an erasable programmable read-only memory(EPROM), a flash memory, or any other computer-readable storage mediathat is capable of storing program instructions or digital information.

In some examples, computer instructions may be stored in local storage608 for implementing, when executed by processor(s) 604, a systemtraffic analyzer described herein, such as the system traffic analyzer106 of FIG. 1.

The media used by local storage 608 may also be removable. For example,a removable hard drive may be used for local storage 608. Other examplesinclude optical and magnetic disks, thumb drives, and smart cards thatare inserted into a drive for transfer onto another computer-readablestorage medium that is also part of local storage 608.

Communications unit 610, in these examples, provides for communicationswith other data processing systems or devices. In these examples,communications unit 610 includes one or more network interface cards.Communications unit 610 may provide communications through the use ofeither or both physical and wireless communications links.

I/O interface(s) 612 allows for input and output of data with otherdevices that may be connected to computing node 600. For example, I/Ointerface(s) 612 may provide a connection to external device(s) 618 suchas a keyboard, a keypad, a touch screen, and/or some other suitableinput device. External device(s) 618 can also include portablecomputer-readable storage media such as, for example, thumb drives,portable optical or magnetic disks, and memory cards. Software and dataused to practice embodiments of the present invention can be stored onsuch portable computer-readable storage media and can be loaded ontolocal storage 608 via I/O interface(s) 612. I/O interface(s) 612 alsoconnect to a display 620.

Display 620 provides a mechanism to display data to a user and may be,for example, a computer monitor.

From the foregoing it will be appreciated that, although specificembodiments have been described herein for purposes of illustration,various modifications may be made while remaining with the scope of theclaimed technology.

What is claimed is:
 1. A distributed system comprising: a firstcomputing node configured to host a first virtual machine and a firstnetwork flow monitor, wherein the first network flow monitor isconfigured to capture a subset of bits of packets sent from the firstvirtual machine; a second computing node configured to host a secondvirtual machine and a second network flow monitor, wherein the secondnetwork flow monitor is configured to capture a subset of bits ofpackets sent from the second virtual machine; a system traffic analyzerconfigured to decode the subset of bits of packets sent from the firstand second virtual machines to determine traffic data, wherein thetraffic data includes a respective source virtual machine identifier anda respective destination virtual machine identifier for each of thesubsets of bits, wherein the system traffic analyzer is furtherconfigured to analyze the respective source and destination virtualmachine identifiers included in the traffic data to determine trafficexchanged between the first virtual machine and the second virtualmachine, wherein the system traffic analyzer is further configured torequest migration of the second virtual machine to the first computingnode in response to a determination that the traffic exchanged betweenthe first virtual machine and the second virtual machine exceeds adynamic threshold level for a defined threshold period of time, whereinthe dynamic threshold level is scheduled to have a first value during afirst portion of a day and is scheduled to have a second value that isdifferent than the first value during a second portion of the day. 2.The distributed system of claim 1, wherein the system traffic analyzercomprises a virtual machine on the first computing node or the secondcomputing node.
 3. The distributed system of claim 1, further comprisinga distributed resource scheduler configured to receive the request tomigrate the second virtual machine and, responsive to the request, tomigrate the second virtual machine to the first computing node from thesecond computing node.
 4. The distributed system of claim 1, wherein thefirst network flow monitor is configured to sample packets by capturinga leading number of bits from a packet as the subset of bits to providethe first sampled packets.
 5. The distributed system of claim 1, whereinthe system traffic analyzer is configured to translate IP addresses fromthe first sampled packets and the second sampled packets into therespective source and destination virtual machine identifiers of thetraffic data.
 6. The distributed system of claim 1, wherein the systemtraffic analyzer is further configured to identify a host computing nodeassociated with a sampled packet of the first sampled packets forinclusion in the traffic data.
 7. The distributed system of claim 1,wherein the system traffic analyzer is further configured to requestmigration of the second virtual machine to the first computing nodefurther in response to the first computing node having a smaller trafficload than the second computing node.
 8. The distributed system of claim7, wherein, when the first computing node has a larger traffic load thanthe second computing node, the system traffic analyzer is furtherconfigured to request migration of the first virtual machine to thesecond computing node in response to a determination that the trafficexchanged between the first virtual machine and the second virtualmachine exceeds the dynamic threshold level for the defined thresholdperiod of time.
 9. A method comprising: sampling network packets sentover a network by first and second virtual machines hosted on first andsecond computing nodes, respectively, of a distributed computing system,by capturing a respective subset of bits of network packets, wherein thenetwork packets are sampled by first and second network flow monitorshosted on the first and second computing nodes, respectively; analyzing,via system traffic analyzer hosted on a computing node of thedistributed computing system, the respective subset of bits to identifyrespective source and destination Internet protocol (IP) addresses; andtranslating, via system traffic analyzer, the respective source anddestination IP addresses into respective virtual machine identifiers;and analyzing, via the system traffic analyzer, the respective virtualmachine identifiers translated from the respective subset of bits todetermine traffic exchanged between the first virtual machine and thesecond virtual machine; and requesting co-location of the first virtualand the second virtual machine to a same computing node of thedistributed computing system when the traffic exchanged between thefirst and second virtual machines exceeds a dynamic threshold level fora defined threshold period of time, wherein the dynamic threshold levelis scheduled to have a first value during a first portion of a day andis scheduled to have a second value that is different than the firstvalue during a second portion of the day.
 10. The method of claim 9wherein the same computing node comprises one of the first or secondcomputing nodes.
 11. The method of claim 9, wherein translating therespective source and destination IP addresses into the respectivevirtual machine identifiers comprises accessing a database configured tostore correlations between IP addresses and virtual machine identifiersin the distributed computing system.
 12. The method of claim 10, furthercomprising selecting the one of the first or second computing nodesbased on a difference in respective traffic loads of the first andsecond computing nodes.
 13. The method of claim 12, further comprisingselecting the one of the first or second computing nodes having asmaller respective traffic load.
 14. A computing node comprising: atleast one processor; computer readable media encoded with instructionswhich, when executed by the at least one processor cause the computingnode to: receive, from first and second network flow monitors hosted onfirst and second computing nodes, respectively, first and second subsetsof bits captured from first and second network packets sent to and fromthe first and second computing nodes, respectively; and decoderespective bits of each of the first and second sampled packets todetermine traffic data, wherein the traffic data includes a respectivesource virtual machine identifier and a respective destination virtualmachine identifier for each of the first and second sampled packets;analyze the respective source and destination virtual machineidentifiers included in the traffic data to determine traffic exchangedbetween a first virtual machine hosted on the first computing node and asecond virtual machine hosted on the computing node; and requestco-location of the first virtual machine and the second virtual machineto a same computing node in response to a determination that the trafficexchanged between the first virtual machine and the second virtualmachine exceeds a dynamic threshold level for a defined threshold periodof time, wherein the dynamic threshold level is scheduled to have afirst value during a first portion of a day and is scheduled to have asecond value that is different than the first value during a secondportion of the day.
 15. The computing node of claim 14, wherein theinstructions, when executed by the at least one processor cause thecomputing node to receive the first and second sampled packets from thefirst and second network flow monitors hosted on respective first andsecond hypervisors executing on the first and second computing nodes.16. The computing node of claim 14, wherein the instructions, whenexecuted by the at least one processor cause the computing node totranslate IP addresses encoded in the bits of the first and secondsampled packets into the respective source and destination virtualmachine identifiers included in the traffic data.
 17. The computing nodeof claim 14, wherein the instructions, when executed by the at least oneprocessor cause the computing node to store a source, destination, andhost from each of the first and second sampled packets in a database asthe traffic data.
 18. The computing node of claim 14, wherein theinstructions, when executed by the at least one processor cause thecomputing node to request co-location of the first and second virtualmachines to one of the first or second computing nodes selected based onwhich of the first and second virtual machines has a least traffic load.19. At least one non-transitory, computer-readable storage mediumincluding with instructions which, when executed by a computing node,cause the computing node to: receive, from first and second network flowmonitors hosted on first and second computing nodes, respectively, firstand second subsets of bits captured from first and second networkpackets sent to and from the first and second computing nodes,respectively; and decode respective bits of each of the first and secondsampled packets to determine traffic data, wherein the traffic dataincludes a respective source virtual machine identifier and a respectivedestination virtual machine identifier for each of the first and secondsampled packets; analyze the respective source and destination virtualmachine identifiers included in the traffic data to determine trafficexchanged between a first virtual machine hosted on the first computingnode and a second virtual machine hosted on the computing node; andrequest co-location of the first virtual machine and the second virtualmachine to a same computing node in response to a determination that thetraffic exchanged between the first virtual machine and the secondvirtual machine exceeds a dynamic threshold level for a definedthreshold period of time, wherein the dynamic threshold level isscheduled to have a first value during a first portion of a day and isscheduled to have a second value that is different than the first valueduring a second portion of the day.
 20. The at least one non-transitory,computer-readable storage medium of claim 19, wherein the instructions,when executed by the computing node cause the computing node totranslate IP addresses encoded in the bits of the first and secondsampled packets into the respective source and destination virtualmachine identifiers included in the traffic data.
 21. The at least onenon-transitory, computer-readable storage medium of claim 19, whereinthe instructions, when executed by the computing node cause thecomputing node to request co-location of the first and second virtualmachines to one of the first or second computing nodes selected based onwhich of the first and second virtual machines has a least traffic load.22. The at least one non-transitory, computer-readable storage medium ofclaim 19, wherein the instructions, when executed by the computing nodecause the computing node to request co-location of the first and secondvirtual machines to a third computing node.